在敏捷開發時,你們都怎麼選擇哪些 backlog要先做?那些 ticket 的優先序都怎麼排的?
如果你的公司和團隊可以明確的分出優先順序,follow 產品 roadmap,那我真的要恭喜你!雖然在敏捷開發中,在每個 sprint 中排定優先任務好像可以遵照一些規則,如上面大家多少也看過的艾森豪 decision matrix,用很直白的概念(重要性與緊急性)決定出決策的優先順序,但現實世界中事情的黑與白真的那麼單純嗎?
我只能說理想很豐滿,但現實很骨感。
以過去我在小小新創的經驗舉例,的確剛開始大家對於 roadmap 都有很美好的想像,也真得以此為根據,排定各功能的優先順序,但當第一個客戶進來時,一切就不一樣了,有時候也不一定是客戶的錯,甚至有時我還會同情他們,因為我們產品根本開發不到20%,他們卻以為他們買到了一隻會飛的大象。
所以當客戶開始使用時,產品根本跟不上客戶需求,這時候就會出現很多插件,不管是功能還是 bug ,有時候還會發生插件比原先排定的任務還多,大家開始哭笑不得,還得在死線前拼命趕工。大家忙了一季過後,才發現一些最重要的部分都還沒開始做,甚至還得回過頭收拾當初趕時間拼出來的板塊,這些後來都有高機率會出問題。
所以我為什麽說需求優先級是一種假象,因為這取決於公司體質,當你體質不好又缺錢醫病時,你其實沒有決定優先級的權利,因為公司要生存而你也需要錢。